Problem Statement

One of the first questions facing development teams is deciding how to organize their code in a source control system. In this article, I will describe an approach that we have applied successfully at multiple organizations over the last decade. I hope it will help you and your team make your development environment and processes leaner and more efficient.

Objectives

First, let's understand what capabilities we are looking for from our source control system:

• Support of the domain-driven design philosophy
• Support of a distributed application development
• Support of a structured, repeatable, and traceable release process

Release Unit

Our source control system is organized around release units. Release Unit can be thought of as a collection of folders and files that are released (and thus, reused) together. It is a job of application architecture to break down a large monolithic application into multiple release units so that they can be tackled independently by different development teams.

Pull and Push Release Unit Dependencies

We recognize two types of dependencies between release units: Push and Pull. Let's assume that Release Unit A depends on Release Unit B. Push dependency means that every time B is changed, it is automatically integrated with A. Pull dependency means that B is integrated into A when A's development team decides to pull a new version of B into A.

An example of Pull Dependency: an application that depends on a shared domain. Even though a new version of the shared domain may be released each month, it does not force the application to be integrated, tested, and redeployed on a monthly basis. Instead, the application integrates with the shared domain only when the application development team decides to pull a new version of the shared domain into the application.

An example of Push Dependency: a web application that depends on the portal's header and footer. Every time, the new header and footer are implemented, each web application is automatically integrated with the new header and footer code.

Implementing Release Unit

We recommend to store a release unit in its own source control folder with the following layout:

/trunk - contains the latest version of the release unit code (may be in progress)
/tags - contains read-only copies of the code (e.g., previous releases of the code into production or test environments)
/branches - contains branch copies of the code

Implementing Pull Dependency

Create /lib folder in your release unit's trunk and place all release unit's pull dependencies there. Configure your release unit to automatically integrate with the dependencies placed in the lib folder. Next month, I will demonstrate how to set up a sample .NET solution structure with pull dependencies.

Implementing Push Dependency

Configure your release unit to link and automatically check out or export all its push dependencies. In Subversion, this can be achieved by using the svn-externals property.

Organizing Release Units

Even a medium-sized organization is likely to have hundreds or even thousands release units in their source control repository. In order to keep the repository manageable and easy to navigate, group release units belonging to the same bounded domain contexts together. For example, you may have a set of release units stored in the Accounting folder, another set stored in the HR folder, and another set stored in the Finance folder. You will need to refer to your domain context map in order to learn what bounded contexts exist in your organization.

5-Step Summary

1. Structure source control to represent your domain context map
2. Develop your applications using multiple release units
3. For each release unit, assign ownership to a dedicated development team
4. Integrate release units via Push and Pull dependencies
5. Establish standard integration and release processes for all release units

Contact me if you have any questions or comments. Happy coding!

We noticed today that one of our ASP.NET cloud applications incorrectly identified the end user's IP address. Our Request.ServerVariables["REMOTE_HOST"] and Request.ServerVariables["REMOTE_ADDR"] were initialized with the load balancer information instead of the end user's data.

We found the end user's IP in a different place: Request.Headers["X-Cluster-client-IP"].

Happy coding!

Modelus.Com site's Terms of Use have been updated. If you post comments on our blog, make sure you read, understand, and agree with our blog comment policy and blog comment guidelines outlined in the Terms of Use.

You can find links to Modelus.Com Terms of Use and Privacy Policy in the footer at the bottom of the page.

The long waited Silverlight 3 and its development tools have been released by Microsoft.

Farewell, Silverlight 2. Welcome, Silverlight 3!

Stuart Halloway, co-founder of Relevance, Inc, will be speaking on Clojure at OTUG on Tuesday, July 21, 2009.

RSVP is required. See more information at http://www.otug.org.

I have been moving a number of web applications from 64-bit Windows Server 2003 and IIS 6 running in 32-bit mode to 64-bit Windows Server 2008 and IIS 7. During testing we discovered the following COM exception when trying to pre-populate an FDF form using FDF toolkit 6:

0x80040154: Retrieving the COM class factory failed.

It turned out that FDF Toolkit 6 has been compiled only for a 32-bit OS. Thus, in order to make it work with IIS 7, you will need to register FDF Toolkit using the 32-bit version of regsvr32.exe. You will also need to enable 32-bit applications in your application pool.

Happy coding!

According to our web statistics, IE8 user base is growing fast at the expense of IE6 and IE7 users. This prompted us to test our web applications using IE8 and, as a result, we discovered a number of CSS and JavaScript compatibility issues.

Most of the JavaScript problems were related to the Dojo 1.1 JavaScript toolkit and all of them have been resolved by upgrading to Dojo 1.3.

If you are wondering which browsers your applications should support, we recommend establishing a rule based on a percentage of your user base. For example, we support 95% of our users, which results in IE 6/7/8, Firefox 3, Chrome 2, and Safari 3 browsers.

Happy coding!

I am pleased to announce that we made our standard templates for A3 reports available as a free download from Modelus.com website: http://modelus.com/Products/A3Templates.aspx.

Earlier this year, I have reviewed Managing to Learn by John Shook and Understanding A3 Thinking by Durward K. Sobek II and Art Smalley. Both of these books have been highly influential on the design of the templates. Check them out.

Enjoy!

This month, we will continue the theme of A3 Thinking started in April with my review of "Managing to Learn" by John Shook.

Durward K. Sobek II and Art Smalley
Understanding A3 Thinking. A Critical Component of Toyota's PDCA Management Process.

In "Managing to Learn", John Shook described the fundamentals of A3 analysis and explained how to apply A3 thinking to improve problem solving and decision making in the organization. In "Understanding A3 Thinking", Durward and Art expanded the scope of A3 reports to two additional categories: proposal reports and status reviews. All three basic types of A3 reports are listed below:

1. Problem-Solving A3 Report
2. Proposal A3 Report
3. Status A3 Report

This book is a practical and insightful introduction to A3 thinking. The authors illustrated how to create different types of A3 reports and included examples, templates, exercises, and review questions for each report category. Additional topics covered include:

• Form and style of the reports
• Commonly used graph types
• Standard A3 templates
• Hand-written vs. electronic A3 reports
• Storage and retrieval of A3's

Where shall you start if you are interested in learning logical, objective, result-focused A3 thinking process?

1. The authors recommend starting by writing a simple problem-solving report with the scope limited to an area you have control over. This way, you will be able to focus on learning the steps of producing an A3 without the complexity of interdepartmental politics.
2. Ask your co-workers as well as your manager/coach for feedback on your A3 report while it is still in progress. Seeking feedback from multiple sources is likely to be very insightful.
3. Continue using A3 reports to analyze, propose, and summarize your daily work processes and projects.

To find more information about this book, click here. Happy reading!

No RSVP is need. See more information on otug.org.